Requirements models, activity models, interface models, parametric models, reliability models, thermal models, power models, finite element models, … the list goes on and on. In this drive towards model-based systems engineering (MBSE) – and ultimately model-based engineering to connect the product lifecycle – how can we make sense of this vast portfolio of models? How can we effectively manage the models and use them to gain leverage over the problem at hand so that we engineer the system rather than becoming distracted by our models? First, we must understand that many so-called models are not models at all (at least not in a sense that brings value to our efforts). Second, we can engineer the model portfolio itself. With apologies to J. R. R. Tolkien, while there may not be one model to rule them all, there certainly is one model to coordinate them all.
If we are to truly engineer systems and not simply stop at ideation, we must address a variety of analytic concerns at the systems level. How do forces propagate? What is the stability of our structure? What is the impact of noise and disturbance? For any given system of interest, there is a key set of analytic dimensions that represent key performance characteristics and constraints that govern system effectiveness. The models for these analytic dimensions are not new. These are the models that engineering disciplines have developed over the years. Which we choose differs based upon the system of interest, and the set of analytic models chosen bring rigor, effectiveness, and efficiency to the systems engineering. These analytic models are often framed in the language, representation, methods of subject matter experts, and they deserve a place in our systems engineering toolbox.
Within the INCOSE community, we often focus on a second type of model – what many call the descriptive systems model, what I often term the architectural systems model. This covers the space from concept of operations through requirements, behavior, physical architecture, and verification & validation. This is where innovation occurs. This is the one chance to manage complexity and address key systems characteristics such as resilience and security. This is what systems engineers represent with a broad set of representations tuned to the audience and the engineer – from IDEF0 to traditional structured representations to SysML and beyond.
This is also where we introduce misunderstanding, often using the term “model” in a manner that breeds confusion rather than clarity. If we use a classic dictionary definition of model, any simplified representation qualifies. In answering the question Is a Document a Model?, we noted how this broad definition leads us astray and into pitfalls rather than progress on our journey to model-based practices. Sometimes people will errantly refer to a requirements model. Requirements are simply a projection of the descriptive system model into the problem domain, not a separate model themselves. Often people refer to individual diagrams – activity, sequence, or interface – as models. Again, these are just projections of the descriptive model that allow us to discuss one particular subset of the system from one particular perspective. There is one and only one architectural model – broad in scope, fundamentally interconnected in nature – and that architectural model connects and coordinates the diverse analytic models.
Much as the systems engineer serves as the technical connective tissue that joins and unifies subject matter experts in solving the systems problem, the architectural model connects the various analytical models of interest. Done well, the architectural model addresses both the problem and solution, reflecting and integrating the key dimensions of both in a manner that clearly reflects the interconnected nature of the system. Done well, the architectural model aligns and maps key terminology across disciplines and concerns, connecting the various perspectives and analytical considerations. As the systems engineer unifies the project team technically, the architectural model is a supporting tool – both at a communication and analytical level – helping the project team explore the problem and solution from a broad range of perspectives.
What is the harm in decoupling various aspects of this descriptive architectural model? In addressing needs, logical solution, physical solution, and V&V, the descriptive model is highly connected. In seeking to decouple the model – into requirements vs physical architecture or into individual views – we lose the interrelationships between the various dimensions. By breaking up the descriptive model, we lose the very richness we seek. We lose the systems perspective, and no amount of patching together with glue can restore it. Systems engineering is all about the relationships, interfaces, and interactions between parts to yield a greater result. We can’t simply assemble stand-alone parts with lightweight connections to deliver the desired system performance. The same is true with the system model.
This does not mean that we are left without methods and techniques to construct, communicate, and analyze the system model. We can take an infinite number of projections of the integrated architectural model in order to describe and understand a particular aspect in the context of the whole. This does not mean that we must all speak the same language. In fact, the systems engineer (and the descriptive model itself) must assume the responsibility of translating from a common systems language to the specialized language of the subject matter expert and back again. In doing so, we always maintain the context and the interrelationships, thereby gaining leverage from new perspectives rather than sacrificing understanding through disjointedness.
Both classes of models – the analytic and the descriptive architectural – are key at the systems level. Both play critical roles in understanding the problem space, in exploring the solution space, in ideation, and ultimately in the engineering of systems. But they are not disjoint. The architectural model serves as the connective tissue coordinating across the diverse analytic models required to bring rigor to our engineering.
As Einstein famously said, “everything should be made as simple as possible, but not simpler.” If we forget the interconnectedness of the descriptive model and oversimplify through separation, we lose the very value that we seek. To deliver the coordination and connectivity we need, we must maintain the systems perspective and recognize the inherent integration of the single descriptive architectural model. We can view projections of the model at countless levels through many different perspectives in many different representations. But there remains one architectural model to coordinate the portfolio of analytic models enabling the effective and efficient engineering of systems.
